Add support for selection-based result filtering in result viewer by asgerf · Pull Request #4362 · github/vscode-codeql

asgerf · 2026-04-09T11:18:06Z

Adds support for selection-based result filtering via a checkbox in the result viewer.

When enabled, only results from the currently-viewed file are shown.
Additionally, if the editor selection is non-empty, only results within the selection range are shown.

A tuple matches the filter if any of its cells contain an entity whose location matches the filter.

selection-filter-cg.mp4

Implementation notes

The result viewer shows results in pages and the webview only has access to its current page. But if we simply apply the filtering on a page-by-page basis, the filtered results could end being scattered across thousands of mostly-empty pages.

The ideal might have been to support for filtering in codeql bqrs like we do for sorting, although that wouldn't work for interpreted results from SARIF files. This is the approach I took:

When the currently-viewed file changes, read the whole BQRS/SARIF in the extension and send the results for that file to the webview.
The webview then post-filters those to the current selection range (if the selection is non-empty).
There is no support for pagination, but the filtering will in practice reduce the number of results so they fit in the UI just fine.

The most complex part of the change is getting the extension <-> webview communication to work well and making sure we don't show stale results regardless of what order UI changes occur in.

The selectedTable state had to be lifted one component up in the hierarchy (from ResultTable to ResultApp) so it is available at the point where we request file-filtered results from the extension.

Copilot

Pull request overview

Adds a selection-based filtering mode to the results viewer. When enabled, the results view is restricted to the currently viewed file (and further restricted to the current editor selection range when the selection is non-empty), with extension ↔ webview messaging to avoid stale/incorrect results.

Changes:

Introduces a “Filter results to current file or selection” checkbox and a dedicated empty-state message for selection-filtered views.
Lifts selectedTable state to ResultsApp and adds new messaging/state to request/receive file-filtered results from the extension.
Implements file/selection filtering helpers for raw rows and SARIF results, and updates UI to show filtered vs total counts and disable pagination while filtering.

Show a summary per file

File	Description
extensions/ql-vscode/src/view/results/SelectionFilterNoResults.tsx	New empty-state UI when selection filtering yields no matches.
extensions/ql-vscode/src/view/results/SelectionFilterCheckbox.tsx	New checkbox control to toggle selection/file filtering.
extensions/ql-vscode/src/view/results/ResultTablesHeader.tsx	Adds pagination-disable mode while selection filtering is active.
extensions/ql-vscode/src/view/results/ResultTables.tsx	Wires checkbox state, disables pagination, computes filtered rows/results and filtered counts.
extensions/ql-vscode/src/view/results/ResultTable.tsx	Applies filtered rows/results to child tables and shows a filter-specific no-results message.
extensions/ql-vscode/src/view/results/ResultsApp.tsx	Lifts selected table state; requests/receives file-filtered results; tracks editor selection/filter state.
extensions/ql-vscode/src/view/results/ResultCount.tsx	Displays filtered/total result counts when filtering is active.
extensions/ql-vscode/src/view/results/result-table-utils.ts	Adds raw-row and SARIF filtering utilities and selection overlap logic.
extensions/ql-vscode/src/local-queries/results-view.ts	Sends editor selection updates; handles file-filtered results requests (BQRS decode + SARIF filtering).
extensions/ql-vscode/src/databases/local-databases/locations.ts	Returns revealed editor/location from jump helpers to support selection updates after navigation.
extensions/ql-vscode/src/common/sarif-utils.ts	Adds helpers to normalize file URIs and extract all locations from SARIF results.
extensions/ql-vscode/src/common/interface-types.ts	Adds shared types/messages for editor selection and file-filtered results.
extensions/ql-vscode/CHANGELOG.md	Documents the new selection-based filtering feature.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comments suppressed due to low confidence (4)

extensions/ql-vscode/src/view/results/ResultTables.tsx:172

When selection filtering disables pagination, offset is still computed from the current pageNumber. If the user enables filtering while on a later page, row numbering (and any offset-based logic in RawTable) will start at a non-zero index even though the view is now showing an unpaged, file-filtered set. Consider using offset = 0 when pagination is disabled / selection filtering is active.

  const offset = parsedResultSets.pageNumber * parsedResultSets.pageSize;

extensions/ql-vscode/src/local-queries/results-view.ts:1204

loadFileFilteredResults decodes the entire result set in one bqrsDecode call using pageSize: schema.rows. For large result sets this can be extremely slow/memory-heavy even if only a small subset matches the file. Consider decoding incrementally using the pagination offsets/page size (and short-circuit once you’ve collected enough matches for the UI), rather than decoding all rows at once.

      if (schema && schema.rows > 0) {
        const resultsPath = query.completedQuery.getResultsPath(selectedTable);
        const chunk = await this.cliServer.bqrsDecode(
          resultsPath,
          schema.name,
          {
            offset: schema.pagination?.offsets[0],
            pageSize: schema.rows,
          },
        );

extensions/ql-vscode/src/local-queries/results-view.ts:1211

The conditional if (schema && schema.rows > 0) means tables with zero rows result in rawRows staying undefined, which can lead to the webview treating file-filtered results as perpetually “loading” (since no concrete empty result is returned). Consider setting rawRows to an empty array when the schema exists but has 0 rows (and/or always returning a FileFilteredResults object for the requested (fileUri, selectedTable), even if both arrays are empty).

      const schema = resultSetSchemas.find((s) => s.name === selectedTable);

      if (schema && schema.rows > 0) {
        const resultsPath = query.completedQuery.getResultsPath(selectedTable);
        const chunk = await this.cliServer.bqrsDecode(
          resultsPath,
          schema.name,
          {
            offset: schema.pagination?.offsets[0],
            pageSize: schema.rows,
          },
        );
        const resultSet = bqrsToResultSet(schema, chunk);
        rawRows = filterRowsByFileUri(resultSet.rows, normalizedFilterUri);
        if (rawRows.length > RAW_RESULTS_LIMIT) {
          rawRows = rawRows.slice(0, RAW_RESULTS_LIMIT);
        }
      }
    } catch (e) {

extensions/ql-vscode/src/local-queries/results-view.ts:1209

rawRows is sliced to RAW_RESULTS_LIMIT before being sent to the webview. This can silently drop matching rows (including ones inside the selection range) and also prevents RawTable from showing its existing "Too many results to show at once… omitted" message because it never sees the full length. Consider sending truncation metadata (or collecting up to the limit while still tracking omitted count) so the UI can indicate that results were truncated.

        const resultSet = bqrsToResultSet(schema, chunk);
        rawRows = filterRowsByFileUri(resultSet.rows, normalizedFilterUri);
        if (rawRows.length > RAW_RESULTS_LIMIT) {
          rawRows = rawRows.slice(0, RAW_RESULTS_LIMIT);
        }

Files reviewed: 13/13 changed files
Comments generated: 4

extensions/ql-vscode/src/view/results/result-table-utils.ts

extensions/ql-vscode/src/view/results/ResultsApp.tsx

extensions/ql-vscode/src/view/results/ResultTables.tsx

extensions/ql-vscode/src/local-queries/results-view.ts

cklin · 2026-04-10T15:28:36Z

Some initial feedback:

Please restructure the PR into smaller, self-contained commits so that they are easier to understand and to review. Ideally the PR would separate into different commits (a) structural changes that are obviously behavior-preserving from (b) behavior changes, with most of the change in the first category, so that I can devote more attention to the parts that need to be reviewed in more detail.
Can you elaborate how you arrived at the design of performing the filtering on the (webview) client side? I would have expected this design:
1. The client side informs the (extension) server side when the state of the filtering checkbox changes
2. The server side applies the filtering (or not) to the results
3. The server side informs the client side that the results have changed
4. The client side fetches the updated results from the server side
The client and the server probably already handle server-side result changes, so steps (iii) and (iv) can use that existing infrastructure. There would be minimal changes on the client side, and existing features (such as result pagination) would "just work" also for filtered results.

I am sure you have reasons for doing things your way, and I want to hear them.

asgerf · 2026-04-13T11:21:59Z

Thanks for looking into this. I'll look into restructuring the commit history when I have time.

As for the way filtering work: It started out being more server-side but state management became too error-prone. There's more state to keep track of than is obvious at first, and you end up with a bunch of fields and patterns of "whenever X changes/happens remember to also do Y". I eventually refactored into the tried and true "React + stateless server" pattern which is less error-prone.

It's hard to remember exactly why it was so hard, other than the fact that there was always one more nuance to deal with, and it felt like the architecture wasn't sound. This is my best attempt at bringing up from memory what the issues were:

Selection and active editor
There are some subtleties around when the editor selection or active-editor change should update the effective selection filter.

Clicking a link in the results view can change the selection and/or active editor, but should not change the selection filter. (Otherwise it's hard to fully explore a set of results that you're focusing on)
But if the user clicks a link and then enables filtering we want the filter to apply to the currently-viewed file.
VSCode doesn't have an "active" editor when the webview has focus so we end up having to remember the last-active editor, yet another thing to track.

Race conditions
There is potential for race conditions between UI events and messages from the extension. The client might request a state change, but then the user quickly clicks a checkbox, then results arrive but now they are stale. If the client doesn't "own" enough state it gets very hard to validate what parts of a setState message is stale.

Pagination
Pagination for BQRS-based results still would not work without also changing codeql bqrs decode to do the file-filtering. We rely on bqrs diff for pagination, but as mentioned, we can't just filter page-by-page as the filtered results can get scattered across thousands of mostly-empty pages.

We'd also have to re-paginate the results whenever the selection changes, preferrably starting using the cached file-filtered results for efficiency. Not impossible to implement or anything, but I wouldn't say we get pagination "for free".

cklin · 2026-04-13T13:26:15Z

Thanks for the additional context! Sounds like server-side filtering is simpler only in theory; in that case client-side filtering makes sense.

Please @-mention me when you are done with the commit restructuring!

For now the checkbox doesn't do anything, we just wire up the state

Just adds the state and messages, and invalidation logic. No actual filtering happens yet

We disable the UI rather than removing it, as removing it causes layout wobbles when toggling the filter checkbox.

Fixes an issue where: - Filtering is disabled - User clicks a link causing a new editor to open - User enables filtering The editor selection would not previously get updated after step 2, leading to incorrect filtering.

cklin

Thank you for breaking the PR down to smaller commits! Just two minor questions.

cklin · 2026-04-14T22:25:16Z

extensions/ql-vscode/src/local-queries/results-view.ts

+    }
+    const selection = this.computeEditorSelection();
+    if (selection === undefined) {
+      return;


I am surprised by the early return here. How would the user revert from selection filtering to whole-file filtering?

cklin · 2026-04-14T22:35:41Z

extensions/ql-vscode/src/local-queries/results-view.ts

+                jumpTarget.uri,
+                jumpTarget.range,
+              ),
+              wasFromUserInteraction: false,


Should wasFromUserInteraction be true here?

asgerf force-pushed the asgerf/filter-results-to-selection branch from 24df5f9 to 86e3e25 Compare April 9, 2026 11:22

asgerf changed the title ~~Adds support for selection-based result filtering in result viewer~~ Add support for selection-based result filtering in result viewer Apr 9, 2026

asgerf force-pushed the asgerf/filter-results-to-selection branch 2 times, most recently from 30ccbf3 to 2bca2f8 Compare April 9, 2026 15:58

asgerf marked this pull request as ready for review April 10, 2026 08:42

asgerf requested review from a team as code owners April 10, 2026 08:42

Copilot AI review requested due to automatic review settings April 10, 2026 08:42

Copilot started reviewing on behalf of asgerf April 10, 2026 08:43 View session

Copilot AI reviewed Apr 10, 2026

View reviewed changes

cklin self-assigned this Apr 10, 2026

asgerf added 14 commits April 14, 2026 07:07

Add change note

ff6f56e

Move problems-view selected state into ResultsApp

efc2606

Move selectedTable state up into ResultsApp

3a1349e

Add a checkbox for enabling selection filtering

690f63a

For now the checkbox doesn't do anything, we just wire up the state

Send editor selection from extension to webview

60598c6

Do not update selection filter when clicking a link

3730d2a

Add state and messages for file-filtered results

679b2c6

Just adds the state and messages, and invalidation logic. No actual filtering happens yet

Compute file-filtered results

9eec6d0

Pass down selection filter data

a9fd7be

Actual show filtered results

08f5361

Render both filtered and total result count

9e6aa15

Show informative message if filter matched nothing

c457d5c

Disable pagination UI when filtering is enabled

e63e601

We disable the UI rather than removing it, as removing it causes layout wobbles when toggling the filter checkbox.

Explicitly notify of editor selection when clicking a link

babc2b8

Fixes an issue where: - Filtering is disabled - User clicks a link causing a new editor to open - User enables filtering The editor selection would not previously get updated after step 2, leading to incorrect filtering.

asgerf force-pushed the asgerf/filter-results-to-selection branch from fa298c5 to babc2b8 Compare April 14, 2026 10:58

cklin reviewed Apr 14, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for selection-based result filtering in result viewer#4362

Add support for selection-based result filtering in result viewer#4362
asgerf wants to merge 14 commits intogithub:mainfrom
asgerf:asgerf/filter-results-to-selection

asgerf commented Apr 9, 2026 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cklin commented Apr 10, 2026

Uh oh!

asgerf commented Apr 13, 2026

Uh oh!

cklin commented Apr 13, 2026

Uh oh!

cklin left a comment

Uh oh!

cklin Apr 14, 2026

Uh oh!

cklin Apr 14, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

asgerf commented Apr 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Implementation notes

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Copilot's findings

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cklin commented Apr 10, 2026

Uh oh!

asgerf commented Apr 13, 2026

Uh oh!

cklin commented Apr 13, 2026

Uh oh!

cklin left a comment

Choose a reason for hiding this comment

Uh oh!

cklin Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

cklin Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

asgerf commented Apr 9, 2026 •

edited

Loading